Skip to content

Conversation

@EZoni
Copy link
Member

@EZoni EZoni commented Nov 10, 2025

Close #38.

To do:

  • Implement new class ElectricMultipoleParameters.
  • Add new tests and make existing tests more symmetric.

@EZoni EZoni added the element parameters element parameters (properties, attributes) label Nov 10, 2025
@EZoni EZoni force-pushed the electric_multipole_parameters branch from 6d57eb5 to 3313a3a Compare November 10, 2025 19:32
@EZoni EZoni marked this pull request as ready for review November 10, 2025 21:47
@EZoni
Copy link
Member Author

EZoni commented Nov 10, 2025

@ax3l @cemitch99

I was looking into duplicating most of the MagneticMultipoleParameters tests for the ElectricMultipoleParameters class, and I ran into a question related to the Quadrupole class.

Is it expected that the ElectricMultipoleP attribute is optional, while the MagneticMultipoleP attribute is mandatory?

class Quadrupole(ThickElement):
"""Quadrupole element"""
# Discriminator field
kind: Literal["Quadrupole"] = "Quadrupole"
# Octupole-specific parameters
ElectricMultipoleP: Optional[ElectricMultipoleParameters] = None
MagneticMultipoleP: MagneticMultipoleParameters

Shouldn't a quadrupole be either electric or magnetic?

@cemitch99
Copy link

@EZoni Here is my point of view: By far the most common usage of "Quadrupole" refers to a magnetic quadrupole, for which all the electric multipole contributions vanish. However, there has been a general trend to allow optional contributions from other parameter groups where reasonable (for example, to support different types of "combined-function" elements). There are also pure electric quadrupoles, for which the same situation applies in reverse (although these are less common). If we wanted to treat electric and magnetic quadrupoles in a symmetric way, there would be two options: 1) create a separate ElectricQuadrupole kind; or 2) require the specification of either magnetic or electric quadrupole components or both (e.g., at least one must be specified). Either option appears reasonable to me.

@EZoni
Copy link
Member Author

EZoni commented Nov 10, 2025

Thanks, @cemitch99!

The standard, https://pals-project.readthedocs.io/en/latest/element-kinds.html#quadrupole-element, seems to go more in the direction of your option 2, "require the specification of either magnetic or electric quadrupole components or both (e.g., at least one must be specified)", since it doesn't mention any ElectricQuadrupole kind.

I think I will propose a change that implements option 2 and see if it works for everyone.

@cemitch99
Copy link

@EZoni That sounds good; I agree it's a simple and clean option.

@EZoni
Copy link
Member Author

EZoni commented Nov 10, 2025

@cemitch99

Do you think the same is true for Sextupole, Octupole, and Multipole?

Right now they seem to allow for no parameter at all, neither MagneticMultipoleP nor ElectricMultipoleP, i.e., both are optional.

For example, we have this

without extra validation logic that requires at least one of the two to be present (like the logic I added in this PR for Quadrupole).

I could fix this in a separate PR, once the "under construction" flag is removed. Do you think this does need a fix indeed?

MagneticMultipoleP: MagneticMultipoleParameters

@model_validator(mode="after")
def validate_at_least_one_multipole(self) -> "Quadrupole":
Copy link
Member Author

@EZoni EZoni Nov 10, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Claude Haiku 4.5 through Visual Studio Code thinks that it is appropriate to include the "Quadrupole" type annotation here:

The string "Quadrupole" is just a type annotation - it doesn't affect what the method actually returns at runtime. The method still returns self (the actual instance object), which is what Pydantic needs. The -> "Quadrupole" is only metadata for type checkers and IDE tools; it doesn't change the runtime behavior at all. The quotes around "Quadrupole" are used because:

  1. The class is still being defined, so we can't reference Quadrupole directly yet (forward reference).
  2. It's equivalent to writing -> Quadrupole after the class definition is complete.

So to be clear: at runtime, the method returns the self object (the actual Quadrupole instance), not a string. The type annotation is purely for static analysis.

@EZoni EZoni requested review from ax3l and cemitch99 November 10, 2025 23:23
@EZoni EZoni changed the title [WIP] Implement ElectricMultipoleParameters Implement ElectricMultipoleParameters Nov 10, 2025
@cemitch99
Copy link

@EZoni I plan to contribute Sextupole, Octupole, and Multipole sections to the standard shortly, since they are simple and widely used. I don't see any good argument for allowing these element kinds with no multipole components at all (since then they have no reason to be classified this way), so adding a validation doesn't hurt. In some ways, it is a bare minimum sanity check.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

element parameters element parameters (properties, attributes)

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Implement ElectricMultipoleParameters

2 participants